Learning Kotlin as a C# Developer
Table of contents
Preamble
Before we dive into this journey, just so you know, I always disliked the Java ecosystem, which started even before I learnt Java more than 15 years ago. Back then, it was pretty underwhelming, not too different from COBOL and PHP.
I never went back to since then, as it always gave me a bitter taste whenever I thought about it. So, here, I'm going to share how I feel about the Java ecosystem from a fresh angle and throw in some comparisons with the .NET world
The start
It’s been quite a while since I picked up a new programming language, and I’m starting to think I might have lost some of my inner ability to learn one anew. I really want to avoid getting stuck in just one ecosystem (and you should probably do the same), so I decided to take another look at Java after 15 years.
Professionally, I mostly use C# with some JavaScript and Python—though I’m not too keen on the Python ecosystem. On the side, I’ve been experimenting a bit with D and keeping an eye on Rust and Zig On the side, as I would like to also give them a proper try at some point.
The setup
As I am exploring the Kotlin programming language and its ecosystem, I wanted to explore the possibility to build and run Kotlin applications with VS Code (I know, I will go in hell for using it), It’s the tool we originally used at my company for C#/.NET projects.
So far, I can see that it is much more difficult to have a working build system for Kotlin going that way than for C#.
In the .NET ecosystem, you basically have to install the .NET SDK (which comes with the runtime), install VS Code, the C# extension and you are good to go. Compiling and running applications is really easy.
In the Kotlin/Java world, things get a bit messier. Sure, you've got to install the right SDK, which is kinda similar, but then it starts getting confusing.
First off, if you want to compile Kotlin apps, you need the Kotlin compiler. That part isn’t too bad—you just download the zip, unzip it wherever you like, add that folder to your $PATH, and you’re set. Now you can start compiling Kotlin applications.
Sadly, if you want a bit more power, equivalent to the dotnet
command-line, which is a complete build system, allowing you to truly manage your .NET projects, you need to install a third-party build system. In the Java world, it seems that you have 2 main choices, either Maven or Gradle (more choices might exist, but those seem to be the most popular ones, which is a probably a good choice to commit to one of them if you want to get a job in the industry).
I went with Gradle mostly because it popped up a lot in Kotlin docs and seemed like the default choice. I'm sorry if you prefer Maven, as I have nothing against it (yet).
Now, almost everything’s set up. All that's left is grabbing those VS Code extensions and I should be good to go.
The struggle
Now for the not-so-fun part of my Kotlin journey.
While I was happy to run kotlinc <file.kt> -include-runtime -d <file.jar>; java -jar <file.jar>
to build and run a simple Hello, world!
example, building and running an application with Gradle seem to not be so easy (under VS Code).
The setup − part 2
I didn't want to spend ages to figure out what are all the things I do not understand yet about Gradle, I am not deep enough into Kotlin to deal with an additional learning curve on a build system. I'm sure it is quite powerful and feature complete, but I want to write a few, reasonably sized Kotlin applications before dealing with all the subtleties of it.
To achieve that goal, let's take a few steps back in the setup. Let's swap VS Code for the community edition of Intellij IDEA. After all, we use Rider at work instead of VS Code now, and that was definitely one of our best calls.
Since JetBrains is behind Kotlin, it makes sense they’d be using Kotlin themselves to build their IDEs (or at least parts of them). That means they’re actively improving the language by putting it to use in real projects.
With the IDE working, it is now time to dive into Kotlin and see how that works out.
The project
To learn Kotlin with something real, I decided to build a ProGuard®[1] mapping parser for Minecraft, to use in a further project (still in Kotlin). The idea is pretty simple:
- Read the local
version_manifest_v2.json
file and parse it - Perform a lookup for a specific Minecraft version (provided at runtime) and get the URL for the specific JSON file for that version
- Load the JSON file in memory from the URL, parse it and retrieve the link to the
client.txt
mapping - Load the text file in memory from the URL, parse it and keep a mapping of the classes, fields and methods
The Good
Coming from C#, Kotlin feels quite unusual. The syntax is clean and relatively intuitive, reducing some boilerplate code.
The documentation online is also really good, easy to read and follow without being too verbose (unlike the Microsoft documentation which is sometimes really hard to follow because of all the verbosity).
The tooling is providing the help you need to learn and improve your code.
The Bad
Even if at first glance, I can see that the Java ecosystem feels less fragmented than before, when everything was sometimes working together by pure luck, it is still not as polished and as integrated than in the .NET world.
Not directly related to Kotlin itself, but I got a really strange bug with Intellij where ALT+UP
won't move a selected line but move the caret to the function definition, which is really annoying when that feature works in all other text editors and IDEs on the market.
The Ugly
Sadly, the project I have in mind requires JNI/JVMTI to be involved. I could continue working on it with Kotlin and compile it to native code, but that would be quite strange to compile a Kotlin program natively, to use a C library to interoperate with a Java application.
What I expected, which seems to not be possible, was to interact with existing classes/objects on the JVM directly through Reflection or some other way to change the behavior of existing methods. Without the use of JNI and JVMTI, it seems that it is not possible, or that I did not find the proper way).
In fact, I didn't use the right tool for this project, even if it should in theory be the case. I will have to find another project to learn Kotlin.
Conclusion
I would like to end this article by answering the following question(s):
- Is it relevant to learn Kotlin
- in 2025?
- as a C# developer?
- instead of Java?
- instead of Rust?
- when AI is going to replace us all in 10 months or less (apparently)?
To answer all those questions, I think learning a new programming language in 2025 is relevant as it will increase your knowledge, help you understand and use things in a different way. It can even make you think differently in your main programming language and give you new ways of doing specific tasks.
It is also quite relevant for a C# developer as the Java ecosystem has still a great market share, and being able to have a foot on that side might be worth in case there is some kind of collapse in the .NET world (unlikely, but the future is never 100% predictable).
As to learn Kotlin instead of Java, I think this is not yet what you should do. Sure, you can start new projects with Kotlin and maintain them without any need to touch Java, but if you have to work for a company where the Java ecosystem is already there, chances are that you will have to maintain an existing Java application.
I would not say that you need to learn Kotlin instead of Rust. In an ideal world, you would learn both as they provide different capabilities and are used in different areas.
When it comes to AI taking over, we're still a few years away from models that can fully understand all our customers' requirements, implement them without any bugs, make sure everything's easily refactorable, and do it cost-effectively.
Right now, AI is trained on past data. And there’s one thing we know for sure: legacy code is always considered awful and garbage. So, should we consider the past as the future of programming and reuse existing code without innovating anymore? I don't think so.
- [1] ProGuard®